(Screenshots with only zoom_level 4 admin boundaries loaded in the database.)

Before:

After:

@nebulon42 @pnorman You have been working on admin boundaries, do you foresee any problems with this approach?

In particular @nebulon42, you added the AND osm_id < 0 requirement, what was the reason for this line of code?

Do you really mean: Split off docs for contributors #723?

Very good to see this.

Is there a reason to show them at all up to z6/7? I can see a rationale for z8+ as it helps identify which country governs certain small islands (though even that's an edge case, and cartographically not one I personally think is worth the sacrifice), but such cases, which are extensively cited in #621, don't especially require the rendering to be made explicit at small scales.

Do you really mean: Split off docs for contributors #723?

I meant #713. Fixed.

Is there a reason to show them at all up to z6/7?

I have no strong opinion on that. Perhaps for the islands in between Greece and Turkey, or between Malaysia and the Phillipines, having the border already at z6/z7 might be useful.

I would like to see worldwide rendering to make sure, but this change looks OK for me in general.

@rrzefox would it be possible to test this on your server?

It depends on the data. The osm_id < 0 vs. osm_id > 0 could indeed make problems. I found that admin boundary information on ways as in contrast to relations was incomplete. Especially in Poland and maybe other regions I don't recall the data was mostly exclusively on relations. I added the < 0 to render only relations as before both relations and ways were rendered which led to duplicated borders and because of the transparency this looked ugly. So the < 0 led to a cleaner rendering and I still think it is important to either render < 0 or > 0.

When I worked on maritime boundaries I also found that maritime = yes was often incomplete. But a different rendering could change that.

So no problems in particular, but double-check on a global rendering. I suspect that we lose quite some amount of boundaries in some regions when switching to rendering boundary ways only.

I see indeed admin_level's missing on boundary (ways) in Poland. Thanks for pointing that out.

All the gray ways on http://product.itoworld.com/map/2 have no admin_level on the boundary ways This applies indeed to Poland, but also to other countries.

I wonder how @cquest solved this issue for the French style?

The osm_id < 0 vs. osm_id > 0 could indeed make problems. I found that admin boundary information on ways as in contrast to relations was incomplete.

The tagging of boundary relations is not only more consistent than that of boundary ways, it is also much more significant. Remove tags from all boundary ways and you will still have perfectly usable boundary information in the database based on the relations. Remove the tags from the boundary relations and you will loose almost everything. Therefore #1989 was a significant step in terms of mapper feedback.

@math1985 I wonder myself ;)

Have a look at the queries near https://github.com/cquest/osmfr-cartocss/blob/master/osmfr.yml#L589

I also did not want to render the boundary portion that are also the coastline... which needs a check in the rels table.

Some maritime boundaries will not render as expected, but it this is because of their incomplete tags, it's a good way to reveal them ;)

@math1985 I wonder myself ;)

It seems you're using admin boundaries only (not relations), meaning the French style does not render the regional admin borders in Poland.

Render demo now at http://bl.ocks.org/math1985/raw/af7a602c222dbf1ff1a2c0d84ed755b7/. Thanks a lot @rrzefox!

And this shows why it's good to do full-planet demos. While the maritime borders seem to look alright, in a lot of other places problems with the land borders show up.

@rrzefox I'm not sure how important regional borders are for the primary purpose of your tile server, but feel free to roll back this change if necessary.

Another issue I see now is that dashed borders consisting of many short lines look much better when rendered as polygon rather than as individual lines. This is because when they are rendered as individual lines, the dash pattern starts again with every new line. This leads to solid lines for borders consisting of sections that are shorter than an individual dash.

If we want to change this color, #2951 makes sense, since despite different properties ferry lines look quite similar. Some internal waters, like Baltic, Mediterranean Sea or Black Sea, look too busy for me on z7 with ferries, and in some cases only z10 is OK, because the border gets wide then.

Another idea: maybe the line should be thicker to compensate the pale color a bit? Color change makes it much less aggressive anyway, so it would be nice to still look different than ferry lines.

I see indeed admin_level's missing on boundary (ways) in Poland. Thanks for pointing that out.

This information is available as a relation tag:

http://www.openstreetmap.org/relation/130935#map=8/52.265/21.195

Do we have a problem with such solution?

Yes, obviously in the relation tag we cannot see what parts of the boundary are maritime.

I’m inclined to encourage the Polish community to add the missing data, especially as most countries do have the data also on lines.

I have already asked about it, when I was not aware that it is done in relations:

https://forum.openstreetmap.org/viewtopic.php?pid=673735#p673735

Maybe a dumb question, but why not render the maritime borders as a slightly broader opaque line based on admin boundary ways on top of the relation based non-maritime polygon borders? If generalization is applied, this may cause issues with alignment, but if none, it might work?

@nebulon42 @pnorman You have been working on admin boundaries, do you foresee any problems with this approach?

There are areas with missing data on ways, like Poland. We rejected going to ways because of the problems there in the past.

Currently what I'm doing for admin boundaries is to take the ways from all admin relations, find min admin_level of parent relations, and apply information like disputed or maritime from way tagging.

Another side effect - the USA/Canada border is invisible in some places, especially on Big Lakes and between Montreal and lake Ontario, because on some zoom levels you don't even see the water line:

http://bl.ocks.org/matthijsmelissen/raw/af7a602c222dbf1ff1a2c0d84ed755b7/#5.00/44.238/-80.454

I have reverted this patch, because it causes rendering failures on high zoom levels:

ERROR: column "maritime" does not exist Full sql was: 'SELECT ST_AsBinary("way") AS geom,"admin_level","maritime" FROM (SELECT way, admin_level, boundary FROM planet_osm_roads WHERE boundary = 'administrative' AND admin_level IN ('0', '1', '2', '3', '4', '5', '6', '7', '8', '9', '10') AND osm_id > 0 ORDER BY admin_level::integer DESC -- With 10 as a valid value, we need to do a numeric ordering, not a text ordering) AS admin_high_zoom

Im guessing this is probably missing a "tags->'maritime' as maritime" somewhere in project.mml...

I updated this.

• Admin rendering based on lines instead of relatinos does not work (lack of data in e.g. Poland, and ugly rendering of dashes in case of short sections). Instead, this renders maritime borders based on lines, on top of the full border based on the polygon.
• Fix error on high zoom levels.
• Render maritime border slightly darker.

Example:

Thanks! This version looks nice and I no longer see the problem with borders being similar to ferry lines. Of course worldwide testing is needed to make sure (for example with the problem mentioned in #2950 (comment)) - @rrzefox Would you like to test it on your server (probably with #3057 too)?

z7

z8

@rrzefox No, no need to test yet. I still plan to make some changes.

Superseded by #3102.

Yes, obviously in the relation tag we cannot see what parts of the boundary are maritime.

Then add a distinguishing tag to the ways, say, boundary:administation=maritime (or equivalent). Duplicating data is not the way to tag differences

I’m inclined to encourage the Polish community to add the missing data, especially as most countries do have the data also on lines.

If admin_level tags are in a relation, no data is missing.
Ways have admin_level tags for two reasons:

• They weren't removed when the relations were added
• They were left under the false belief they were essential for renderers. They are not. Boundary maps can be produced by assessing the relations alone.